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Abstract 

We  present  a  system  for  extending  standard  type  systems  with  flow-sensitive  type  qualifiers.  Users 
annotate  their  programs  with  type  qualifiers,  and  inference  checks  that  the  annotations  are  correct. 
In  our  system  only  the  type  qualifiers  are  modeled  flow-sensitively — the  underlying  standard  types  are 
unchanged,  which  allows  us  to  obtain  an  efficient  constraint-based  inference  algorithm  that  integrates 
flow-insensitive  alias  analysis,  effect  inference,  and  ideas  from  linear  type  systems  to  support  strong 
updates.  We  demonstrate  the  usefulness  of  flow-sensitive  type  qualifiers  by  finding  a  number  of  new 
locking  bugs  in  the  Linux  kernel. 


1  Introduction 

Standard  type  systems  are  flow-insensitive ,  meaning  a  value’s  type  is  the  same  everywhere.  However,  many 
important  properties  are  flow-sensitive.  Checking  such  properties  requires  associating  different  facts  with  a 
value  at  different  program  points. 

This  paper  shows  how  to  extend  standard  type  systems  with  user-specified  flow-sensitive  type  qualifiers, 
which  are  atomic  properties  that  refine  standard  types.  In  our  system  users  annotate  programs  with  type 
qualifiers,  and  inference  checks  that  the  annotations  are  correct.  The  critical  feature  of  our  approach  is 
that  flow-sensitivity  is  restricted  to  the  type  qualifiers  that  decorate  types — the  underlying  standard  types 
are  unchanged — which  allows  us  to  obtain  an  efficient  type  inference  algorithm.  Type  qualifiers  capture  a 
natural  class  of  flow-sensitive  properties,  while  efficient  inference  of  the  type  qualifiers  allows  us  to  apply  an 
implementation  to  large  code  bases  with  few  user  annotations. 

For  an  example  of  type  qualifiers,  consider  the  type  File  used  for  I/O  operations  on  files.  In  most 
systems  File  operations  can  only  be  used  in  certain  ways:  a  file  must  be  opened  for  reading  before  it 
is  read,  it  must  be  opened  for  writing  before  it  is  written  to,  and  once  closed  a  file  cannot  be  accessed. 
We  can  express  these  rules  with  flow-sensitive  type  qualifiers.  We  introduce  qualifiers  open,  read,  write, 
readwrite,  and  closed.  The  type  open  File  describes  a  file  that  has  been  opened  in  an  unknown  mode, 
the  type  read  File  (respectively  write  File)  is  a  file  that  is  open  for  reading  (respectively  writing),  the 
type  readwrite  File  is  a  file  open  for  both  reading  and  writing,  and  the  type  closed  File  is  a  closed  file. 
These  qualifiers  capture  inherently  flow-sensitive  properties.  For  example,  the  close  ()  function  takes  an 
open  File  as  an  argument  and  changes  the  file’s  state  to  closed  File. 

These  qualifiers  have  a  natural  subtyping  relation,  shown  in  Figure  1.  The  qualifier  closed  is  incompa¬ 
rable  to  other  qualifiers  because  a  file  may  not  be  both  closed  and  open.  Qualifiers  that  introduce  subtyping 
are  very  common,  and  our  framework  supports  subtyping  directly;  in  addition  to  a  set  of  qualifiers,  users 
can  define  a  partial  order  on  the  qualifiers. 

‘This  research  was  supported  in  part  by  NSF  CCR-9457812,  NASA  Contract  No.  NAG2-1210,  NSF  CCR-0085949,  and 
DARPA  Contract  No.  F33615-00-C-1693. 
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Figure  1:  Subtyping  relation  among  File  qualifiers 


Our  results  build  on  recent  advances  in  flow-sensitive  type  systems  [CWM99,  SWMOO,  DF01]  as  well  as 
our  own  previous  work  on  flow-insensitive  type  qualifiers  [FFA99].  The  main  contribution  of  our  work  is 
a  practical,  flow-sensitive  type  inference  algorithm,  in  contrast  to  the  type  checking  systems  of  [CWM99, 
SWMOO,  DF01], 

Our  flow-sensitive  type  inference  algorithm  is  made  practical  by  solving  constraints  lazily.  As  in  any  flow- 
sensitive  analysis,  explicitly  forming  a  model  of  the  store  at  every  program  point  is  prohibitively  expensive 
for  large  code  bases.  By  generating  a  linear-size  constraint  system  from  the  original  program  and  solving 
only  the  portion  of  the  constraints  needed  to  check  qualifier  annotations,  our  algorithm  is  able  to  scale  to 
large  examples. 

Finally,  our  system  is  designed  to  be  sound;  we  aim  to  prove  the  absence  of  bugs,  not  just  to  be  heuris- 
tically  good  at  finding  bugs.  For  example,  we  believe  that  our  system  could  be  integrated  into  Java  in  a 
sound  manner.  We  have  shown  soundness  for  restrict  (Section  4),  a  key  new  construct  in  our  system  (see 
technical  report  [FA01]).  Since  the  remainder  of  our  system  can  be  viewed  as  a  simplification  of  [SWMOO], 
we  believe  it  is  straightforward  to  prove  soundness  for  our  full  type  system  using  their  techniques. 

In  Section  5  we  report  on  experience  with  two  applications,  analyzing  locking  behavior  in  the  Linux 
kernel  and  analyzing  C  stream  library  usage  in  application  code.  Our  system  found  a  number  of  new  locking 
bugs,  including  some  that  extend  across  multiple  functions  or  even,  in  one  case,  across  multiple  files. 

1.1  System  Architecture 

Our  flow-sensitive  qualifier  inference  algorithm  has  several  interlocking  components.  We  first  give  an  overview 
of  the  major  pieces  and  how  they  fit  together. 

We  expect  programmers  to  interact  with  our  type  system,  both  when  adding  qualifier  annotations  and 
when  reviewing  the  results  of  inference.  Thus,  we  seek  a  system  that  supports  efficient  inference  and  is 
straightforward  for  a  programmer  to  understand  and  use.  Our  type  inference  system  integrates  alias  analysis, 
effect  inference,  and  ideas  from  linear  type  systems. 

•  We  use  a  flow-insensitive  alias  analysis  to  construct  a  model  of  the  store.  The  alias  analysis  infers 
an  abstract  location  for  the  result  of  each  program  expression;  expressions  that  evaluate  to  the  same 
abstract  location  may  be  aliased. 

•  We  use  effect  inference  [LG88]  to  calculate  the  set  of  abstract  locations  an  expression  e  might  use 
during  e’s  evaluation.  These  effects  are  used  in  analyzing  function  calls  and  restrict  (see  below). 
Effect  inference  is  done  simultaneously  with  alias  analysis. 

•  We  model  the  state  at  a  program  point  as  an  abstract  store ,  which  is  a  mapping  from  abstract  locations 
to  types.  We  can  use  the  abstract  locations  from  the  flow-insensitive  alias  analysis  because  we  allow 
only  the  type  qualifiers,  and  not  the  underlying  standard  types,  to  change  during  execution.  We 
represent  abstract  stores  using  a  constraint  formalism.  Store  constructors  model  allocations,  updates, 
and  function  calls,  and  store  constraints  C\  <  Co  model  a  branch  from  the  program  point  represented 
by  store  C\  to  the  program  point  represented  by  store  Co. 

•  We  compute  a  linearity  [SWMOO]  for  each  abstract  location  at  each  program  point.  Informally,  an 
abstract  location  is  linear  if  the  type  system  can  prove  that  it  corresponds  to  a  single  concrete  location 
in  every  execution;  otherwise,  it  is  non-linear.  We  perform  strong  updates  [CWZ90]  on  locations  that 
are  linear  and  weak  updates  on  locations  that  are  non-linear.  A  strong  update  can  change  the  qualifier 
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on  a  location’s  type  arbitrarily.  Weak  updates  cannot  change  qualifiers.  Computing  linearities  is 
important  because  most  interesting  flow-sensitive  properties  require  strong  updates. 

•  The  system  described  so  far  has  a  serious  practical  weakness:  Type  inference  may  fail  because  a 
location  on  which  a  strong  update  is  needed  may  be  inferred  to  be  non-linear.  We  address  this  with 
a  new  annotation  restrict.  The  expression  restrict x  =e  in e'  introduces  a  new  name  x  bound  to 
the  value  of  e.  The  name  x  is  given  a  fresh  abstract  location,  and  among  all  aliases  of  e,  only  x  and 
values  derived  from  x  may  be  used  within  e'.  Thus  the  location  of  x  may  be  linear,  and  hence  may  be 
strongly  updated,  even  if  the  location  of  e  is  non-linear.  We  use  effects  to  enforce  the  correctness  of 
restrict  expressions — soundness  requires  that  the  location  of  e  does  not  appear  in  the  effect  of  e'. 

•  We  use  effects  to  increase  the  precision  of  the  analysis.  If  an  expression  e  does  not  reference  location 
p,  which  we  can  determine  by  examining  the  effect  of  e,  then  it  cannot  change  the  value  stored  at  p, 
and  the  analysis  of  p  can  simply  flow  from  the  store  preceding  e  to  the  one  immediately  after  e  without 
passing  through  e.  If  e  is  an  application  of  a  function  called  in  many  different  contexts,  then  this  idea 
makes  e  fully  polymorphic  in  all  the  locations  that  e  does  not  reference. 


2  Related  Work 

We  discuss  three  threads  of  related  work:  type  systems,  dataflow  analysis,  and  tools  for  finding  bugs  in 
software. 

Type  Systems.  Our  type  system  is  inspired  by  region  and  alias  type  checking  systems  designed  for  low- 
level  programs  [CWM99,  SWMOO,  WMOO].  Two  recent  language  proposals,  Vault  [DF01]  and  Cyclone 
[GMW+01],  adapt  similar  ideas  for  checking  high-level  programs.  Both  of  these  languages  are  based  on 
type  checking  and  require  programmers  to  annotate  their  programs  with  types.  In  contrast,  we  propose 
a  simpler  and  less  expressive  monomorphic  type  system  that  is  designed  for  efficient  type  inference.  Our 
system  incorporates  effect  inference  [LG88,  Wri92]  to  gain  a  measure  of  polymorphism. 

The  type  state  system  of  NIL  [SY86]  is  one  of  the  earliest  to  incorporate  flow-sensitive  type  checking.  Xu 
et  al  [XRM01]  use  a  flow-sensitive  analysis  to  check  type  safety  of  machine  code.  Type  systems  developed 
for  Java  byte  code  [SA98,  0’C99]  also  incorporate  flow-sensitivity  to  check  for  initialization  before  use  and 
to  allow  reuse  of  the  same  local  variable  with  different  types. 

Igarashi  and  K obayashi  [IK02]  propose  a  general  framework  for  resource  usage  analysis,  which  associates 
a  trace  with  each  object  specifying  valid  accesses  to  the  object,  and  checks  that  the  program  satisfies  the 
trace  specifications.  They  provide  an  inference  algorithm,  although  it  is  unclear  how  efficient  it  is  in  practice 
since  it  invokes  as  a  sub-step  an  unspecified  algorithm  to  check  that  a  trace  set  is  valid. 

Flanagan  and  Freund  [FFOO]  use  a  type  checking  system  to  verify  Java  locking  behavior.  In  Java  locks  are 
acquired  and  released  according  to  a  lexical  discipline.  To  model  locking  in  the  Linux  kernel  (as  in  Section  5) 
we  must  allow  non-lexically  scoped  lock  acquires  and  releases. 

The  subset  of  our  system  consisting  of  alias  analysis  and  effect  inference  can  be  seen  as  a  monomorphic 
variant  of  region  inference  [TT94],  The  improvements  to  region  inference  reported  in  [AFL95]  are  a  much 
more  expensive  and  precise  method  for  computing  linearities. 

Dataflow  Analysis.  Although  our  type-based  approach  is  related  to  dataflow  analysis  [ASU88],  it  differs 
from  classical  dataflow  analysis  in  several  ways.  First,  we  generate  constraints  over  stores  and  types  to  model 
the  program.  Thus  there  is  no  distinction  between  forward  and  backward  analysis — information  may  flow 
in  both  directions  during  constraint  resolution,  depending  on  the  specified  qualifier  partial  order.  Second, 
we  explicitly  handle  pointers,  heap-allocated  data,  aliasing,  and  strong/weak  updates.  Third,  there  is  no 
distinction  between  interprocedural  and  intraprocedural  analysis  in  our  system. 

The  strong/weak  update  distinction  was  first  described  by  Chase  et  al  [CWZ90].  Several  techniques  that 
allow  strong  updates  have  been  proposed  for  dataflow-based  analysis  of  programs  with  pointers,  among  them 
[EGH94,  AL95,  WL95].  Jagannathan  et  al  [JTWW98]  present  a  system  for  must-alias  analysis  of  higher- 
order  languages.  The  linearity  computation  in  our  system  corresponds  to  their  singleness  computation,  and 
they  use  a  similar  technique  to  gain  polymorphism  by  flowing  some  bindings  around  function  calls. 
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Bug-Finding  Tools.  The  AST  Toolkit  provides  a  framework  for  posing  user-specified  queries  on  abstract 
syntax  trees  annotated  with  type  information.  The  AST  Toolkit  has  been  successfully  used  to  uncover  many 
bugs  [WeiOl]. 

Meta-level  compilation  [ECCHOO]  is  a  system  for  finding  bugs  in  programs.  The  programmer  specifies  a 
flow-sensitive  property  as  an  finite  state  automaton.  A  program  is  analyzed  by  traversing  control  paths  and 
triggering  state  transitions  of  the  automata  on  particular  actions  in  program  statements.  The  system  warns 
of  potential  errors  when  an  automaton  enters  an  error  state.  In  [ECCHOO]  an  intraprocedural  analysis  of  lock 
usage  in  the  Linux  kernel  uncovered  many  local  locking  bugs.  Our  type-based  system  found  mferprocedural 
locking  bugs  that  extended  across  multiple  functions  or  even,  in  one  case,  across  multiple  files  (Section  5).1 
Newer  work  on  meta-level  compilation  [ECH+01]  includes  some  interprocedural  dataflow,  but  it  is  unclear 
how  their  interprocedural  dataflow  analysis  handles  aliasing. 

LCLint  [Eva96]  is  a  dataflow-based  tool  for  checking  properties  of  programs.  To  use  LCLint,  the  pro¬ 
grammer  adds  extra  annotations  to  their  program,  just  like  our  type  qualifier  system.  LCLint  performs 
flow-sensitive  intraprocedural  analysis,  using  the  programmer’s  annotations  at  function  calls. 


3  Type  System 

We  describe  our  type  system  using  a  call-by-value  lambda  calculus  extended  with  pointers  and  type  qualifier 
annotations.  The  source  language  is 

e  ::=  x  \  n  \  Xx.e  \  e\  e%  |  ref  e  \  \e  \  e\  :  =  e-2  |  assert (e,Q)  |  check(e,  Q) 

Here  x  is  a  variable,  n  is  an  integer,  Xx.e  is  a  function  with  argument  x  and  body  e,  the  expression  e\  eo  is 
the  application  of  function  e\  to  argument  eo,  the  expression  ref  e  allocates  memory  and  initializes  it  to  e, 
the  expression  !e  dereferences  pointer  e,  and  the  expression  e\  :  =  eo  assigns  the  value  of  e-2  to  the  location 
e\  points  to. 

We  introduce  qualifiers  into  the  source  language  by  adding  two  new  forms  [FFA99].  The  expression 
assert(e,Q)  asserts  that  e’s  top-level  qualifier  is  Q,  and  the  expression  check(e,<2)  type  checks  only  if  e’s 
top-level  qualifier  is  at  most  Q. 

Our  type  inference  algorithm  is  divided  into  two  steps.  First  we  perform  an  initial  flow-insensitive  alias 
analysis  and  effect  inference.  Second  we  generate  and  solve  store  and  qualifier  constraints  and  compute 
linearities. 

3.1  Alias  Analysis  and  Effect  Inference 

We  present  the  flow-insensitive  alias  analysis  and  effect  inference  as  a  translation  system  rewriting  source 
expressions  to  expressions  decorated  with  locations,  types,  and  effects.  The  target  language  is 

e  ::=  x  \  n  \  X Lx:t.e  \  e\  eo  |  ref p  e  \  \e  \  e\  :  =  eo 
j  assert(e,  Q)  |  check(e,<2) 
t.  ::=  a  \  int  \  ref(p)  \  t  — >L  t' 

L  ::=  ip  |  {p}  |  L\  U  Lo  |  L\  f~l  Lo 

The  target  language  extends  the  source  language  syntax  in  two  ways.  Every  allocation  site  ref p  e  is  annotated 
with  the  abstract  location  p  that  is  allocated,  and  each  function  A Lx:t..e  is  annotated  with  both  the  type 
t  of  its  parameter  and  the  effect  L  of  calling  the  function.  Effects  are  unions  and  intersections  of  effect 
variables  ip,  which  represent  an  unknown  set  of  effects,  and  effect  constants  p,  which  stands  for  a  read,  write, 
or  allocation  of  location  p. 

Foreshadowing  flow-sensitive  analysis,  pointer  types  are  written  ref(p),  and  we  maintain  a  separate  global 
abstract  store  Ci  mapping  locations  p  to  types;  C/(p)  =  r  if  location  p  contains  data  of  type  r.  If  type 
inference  requires  p  =  p' ,  we  also  require  Cj(p)  =  Cj(p').  Function  types  t  — >L  t!  contain  the  effect  L  of 
calling  the  function. 

lrThe  bugs  were  found  in  a  newer  version  of  the  Linux  kernel  than  examined  by  [ECCHOO],  so  a  direct  comparison  is  not 
possible,  though  these  bugs  cannot  be  found  by  purely  intraprocedural  analysis. 
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Figure  2:  Type,  alias,  and  effect  inference 


Figure  2  gives  rules  for  performing  alias  analysis  and  effect  inference  while  translating  source  programs 
into  our  target  language.  This  translation  system  proves  judgments  rhe^-ehijL,  meaning  that  in  type 
environment  V .  expression  e  translates  to  expression  e',  which  has  type  t ,  and  the  evaluation  of  e  may  have 
effect  L. 

The  set  of  locations  appearing  in  a  type,  locs{t ),  is 

locs(  int )  =  0 

Iocs  (ref  ip))  =  {p}  U  locs(Ci(p)) 

locs(t,\  — >L  t.-i)  =  locs(ti)  U  locsit-i)  U  L 

We  assume  that  locs(a)  is  empty  until  a  is  equated  with  a  constructed  type.  We  define  locs(T)  to  be 
U,->igr  locs W- 

We  briefly  discuss  the  rules  in  Figure  2: 

•  (Var)  and  (Int)  are  standard.  In  lambda  calculus,  a  variable  is  an  r-value,  not  an  (-value,  and  accessing 
a  variable  has  no  effect. 

•  (Ref)  allocates  a  fresh  abstract  location  p.  We  add  the  effect  p  of  the  allocation  to  the  effect  and  record 
in  Ci  the  type  to  which  the  location  p  points. 

•  (Deref)  evaluates  e,  which  yields  a  pointer  to  a  location  p.  We  look  up  the  type  of  location  p  in  Cj 
and  add  p  to  the  effect  set. 
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fun  /  w  = 

let  x  =  ref  0 

y  =  ref  (assert  (1,  qa)) 
z  =  ref  (assert  (2,  g&)) 
in 

/*  Write  to  a~’s  cell  */ 
x  :  =  3 
w  :  =  4 

2/  :  =  assert(5,gc) 
if  (...) 

/  s 

check(  !g,gc) 

(a)  Source  program 


fuidP2*/  w:  ref(pz)  = 
let  x  =  ref  Pl  0 

V  =  ref Py  (assert(l,  ga  )) 
t  =  refP2  (assert(2,  gQ) 
in 

x  :  =  3 
w  :  =  4 

y  :  =  assert(5,gc) 
if  (...) 

/  K 

check(  \y,qc) 

(b)  Target  program 


Ci(px)  =  Ci(py)  =  Ci(pz)  =  int 
Figure  3:  Example  alias  and  effect  analysis 


•  (Assign)  writes  a  location.  Note  that  the  type  of  e-2  and  the  type  that  ei  points  to  are  equated.  Because 
types  contain  locations,  this  forces  potentially  aliased  locations  to  be  modeled  by  one  abstract  location. 

•  (Lam)  defines  a  function.  We  annotate  the  function  with  the  effect  ip  of  the  function  body  and  the 
type  a  of  the  parameter.  Function  types  always  have  an  effect  variable  ip  on  the  arrow,  which  makes 
effect  inference  easier.  Notice  that  creating  a  function  has  no  effect. 

•  (App)  applies  a  function  to  an  argument.  The  effect  of  applying  ei  to  eo  includes  the  effect  tp  of  calling 
the  function  ei  represents.  Notice  that  ei’s  argument  type  is  constrained  to  be  equal  to  the  type  of  eo. 
As  before,  this  forces  possibly  aliased  locations  to  have  the  same  abstract  location. 

•  (Assert)  and  (Check)  are  translated  unchanged  into  the  target  language.  Qualifiers  are  flow-sensitive, 
so  we  do  not  model  them  during  this  first,  flow-insensitive  step  of  the  algorithm. 

•  (Down)  hides  effects  on  purely  local  state.  If  evaluating  e  produces  an  effect  on  some  location  p  neither 
in  T  nor  in  t ,  then  p  cannot  be  accessed  in  subsequent  computation.  By  intersecting  the  effects  L 
with  effects  that  may  be  visible  locs(T,t),  we  increase  the  precision  of  effect  inference,  which  in  turn 
increases  the  precision  of  flow-sensitive  type  qualifier  inference.  Although  (Down)  is  not  a  syntactic 
rule,  it  only  needs  to  be  applied  once  per  function  body  [FA01]. 

Figure  3  shows  an  example  program  and  its  translation.  We  use  some  syntactic  sugar;  all  of  these 
constructs  can  be  encoded  in  our  language  (e.g.,  by  assuming  a  primitive  Y  combinator  of  the  appropriate 
type).  In  this  example  the  constant  qualifiers  qa,  qt,,  and  qc  are  in  the  discrete  partial  order  (the  qualifiers 
are  incomparable).  Just  before  /  returns,  we  wish  to  check  that  y  has  the  qualifier  qc.  This  check  succeeds 
only  if  we  can  model  the  update  to  y  as  a  strong  update. 

In  Figure  3,  we  assign  x ,  y,  and  z  distinct  locations  px ,  py,  and  pz,  respectively.  Because  /  is  called  with 
argument  z,  our  alias  analysis  requires  that  the  types  of  z  and  w  match,  and  thus  w  is  given  the  type  ref(pz). 
Finally,  notice  that  since  x  and  y  are  purely  local  to  the  body  of  /,  using  the  rule  (Down)  our  analysis  hides 
all  effects  on  px  and  pv.  The  effect  of  /  contains  pz  because  /  writes  to  its  parameter  w,  which  has  type 
ref(pz). 

Let  n  be  the  size  of  the  input  program.  Applying  the  rules  in  Figure  2  generates  a  constraint  system  of 
size  O(n),  using  a  suitable  representation  of  locs{T,t)  (see  [FA01]).  Resolving  the  type  equality  constraints 
in  the  usual  way  with  unification  takes  0(na(n ))  time,  where  a(-)  is  the  inverse  Ackerman’s  function.  The 
remaining  constraints  are  effect  constraints  of  the  form  L  C  ip.  We  solve  these  constraints  on-demand — in 
the  next  step  of  the  algorithm  we  will  ask  queries  of  the  form  p  6  L.  We  can  answer  all  such  queries  for  a 
single  location  p  in  0(n )  time. 
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3.2  Stores  and  Qualified  Types 

Next  we  perform  flow-sensitive  analysis  to  check  the  qualifier-related  annotations.  In  this  second  step  of  the 
algorithm  we  take  as  input  a  program  decorated  with  types,  locations,  and  effects  by  the  inference  algorithm 
of  Figure  2.  Throughout  this  step  we  treat  the  abstract  locations  p  and  effects  L  from  the  first  step  as 
constants.  We  analyze  the  input  program  using  the  extended  types  shown  below: 

r  ::=  Q  a 
Q  ::=  k  |  B 

a  ::=  a\  int  \  ref(p)  \  ( C,r )  — >L  ( C',r ') 

C  ::=  c  |  Alloc(C,p)  \  Assign(C,p  :  r)  |  Merge(C,C'  ,  T)  \  Filter(C,  L) 
p  ::=  0  |  1  |  ui 

Here  qualified  types  r  are  standard  types  with  qualifiers  inserted  at  every  level.  Qualifiers  Q  are  either 
qualifier  variables  k,  which  stand  for  currently  unknown  qualifiers,  or  constant  qualifiers  B,  specified  by  the 
user.  We  assume  a  supplied  partial  order  <  among  type  qualifiers. 

Flow-sensitive  analysis  associates  a  store  C  with  each  program  point.  This  is  in  contrast  to  the  flow- 
insensitive  step,  which  uses  one  global  store  Cj  to  give  types  to  locations.  Function  types  are  extended  to 
(C,  t)  — >L  { C',t '),  where  C  describes  the  store  the  function  is  invoked  in  and  C'  describes  the  store  when 
the  function  returns. 

Each  location  in  each  store  has  an  associated  lineality  p.  There  are  three  linearities:  0  for  unallocated 
locations,  1  for  linear  locations  (these  admit  strong  updates),  and  ui  for  non-linear  locations  (which  admit 
only  weak  updates).  The  three  linearities  form  a  lattice  0  <  1  <  u.  Addition  on  linearities  is  as  expected: 
0  +  x  =  x,  l  +  l  =  o;,  and  u>  +  x  =  u>. 

Formally  a  store  is  a  vector  assigning  a  type  and  a  linearity  to  every  abstract  location  computed  by  the 
alias  analysis: 

{pfi  :ris. . .  ,pln  ;r„} 

We  call  such  a  vector  a  ground  store.  If  G  is  a  ground  store,  we  write  G(p )  for  p’s  type  in  G,  and  we  write 
Gnn{p)  for  p’s  linearity  in  G. 

Rather  than  explicitly  associating  a  ground  store  with  every  program  point,  we  represent  stores  using 
a  constraint  formalism.  As  the  base  case,  we  model  an  unknown  store  using  a  store  variable  e.  We  relate 
stores  at  consecutive  program  points  either  with  store  constructors  (see  below),  which  build  new  stores  from 
old  stores,  or  with  store  constraints  C i  <  Co,  which  are  generated  at  branches  from  the  program  point 
represented  by  store  C\  to  the  program  point  represented  by  store  Co. 

A  solution  to  a  system  of  store  constraints  is  a  mapping  from  store  variables  to  ground  stores.  A  solution 
S  satisfies  a  system  of  store  constraints  if  for  each  constraint  C i  <  Co  we  have  S'(Ci)  <  5(Co)  according  to 
the  rules  in  Figure  4. 

In  Figure  4,  constraints  between  stores  yield  constraints  between  linearities  and  types,  which  in  turn  yield 
constraints  between  qualifiers  and  between  stores.  In  our  constraint  resolution  algorithm,  we  exploit  the  fact 
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S(Alloc(C,p'))(p) 

S(Merge(C,C,L))(p) 
S(Filter{C,  L))(p) 

S {Assign(C,  p  :  r)){p) 


S(C)(p) 

S(C)(P)  peL 
S(C')(p)  otherwise 

S(C)(p)  p  &  L 

T  p=  p 

S(C)(p)  otherwise 


(a)  Types 


S(Alloc(C,p'))lm(p) 


S(Merge(C,C',L))lm(p) 


S(Filter(C,L))lin(p) 
S(Assign(C,  p'  :  r))lin(p) 


{ 

{ 

{ 


l  +  S{C)im(p)  P  =  P 
S(C)Un(p)  otherwise 

S{C)lm(p)  peL 
S(C')lm(p)  otherwise 


S(Chm(p'>  PeL 

0  otherwise 


S(C)lm(p) 


(b)  Linearities 


S(dli„(p)  =  00  T  =  S(C)(p)  for  all  stores  Assign(C,  p  :  r) 

(c)  Weak  updates 


Figure  5:  Extending  a  solution  to  constructed  stores 


that  we  are  only  interested  in  qualifier  relationships  to  solve  as  little  of  the  expensive  store  constraints  as 
possible. 

In  (Ref<)  we  require  that  the  locations  on  the  left-  and  right-hand  sides  of  the  <  are  the  same.  Alias 
analysis  enforces  this  property,  which  corresponds  to  the  standard  requirement  that  subtyping  becomes 
equality  below  a  pointer  constructor.  We  emphasize  that  in  this  step  we  treat  abstract  locations  p  as 
constants,  and  we  will  never  attempt  (or  need)  to  unify  two  distinct  locations  to  satisfy  (Ref<). 

In  (Fun<)  we  require  that  the  effects  of  the  constrained  function  types  match  exactly. 

Figure  5  formalizes  the  four  kinds  of  store  constructors  by  showing  how  a  solution  S  mapping  store 
variables  to  ground  stores  is  extended  to  constructed  stores. 

The  store  Alloc{C,p)  is  the  same  as  store  C,  except  that  location  p  has  been  allocated  once  more. 
Allocating  location  p  does  not  affect  the  types  in  the  store  but  increases  the  linearity  of  location  p  by  one. 

The  store  Merge(C ,  C',L )  combines  stores  C  and  C'  according  to  effect  L.  If  p  £  L,  then  Merge(C ,  C' ,  L) 
assigns  p  the  type  it  has  in  C,  otherwise  Merge(C,C'  ,L)  assigns  p  the  type  it  has  in  C' .  The  linearity 
definition  is  similar. 

The  store  Filter(C,  L)  assigns  the  same  types  and  linearities  as  C  for  all  locations  p  such  that  p  G  L.  The 
types  of  all  other  locations  are  undefined,  and  the  linearities  of  all  other  locations  are  0. 

Finally,  the  store  Assign(C,  p  :  r)  is  the  same  as  store  C ,  except  location  p  is  given  type  r.  If  p  is 
non-linear  in  (7,  then  we  require  that  r  be  equal  to  the  type  of  p  in  C\  this  corresponds  to  a  weak  update. 

3.3  Flow- Sensitive  Constraint  Generation 

Figure  6  gives  the  type  inference  rules  for  our  system.  In  this  system  judgments  have  the  form  r,Che:r,C', 
meaning  that  in  type  environment  F  and  with  initial  store  C,  evaluating  e  yields  a  result  of  type  r  and  a  new 
store  C'.  We  write  C(p)  for  the  type  associated  with  p  in  store  C ;  we  discuss  the  computation  of  C(p)  in 


x  G  dom{T) 


r.r  x  :  n.r).r 

k  fresh 


(Var) 

■  (Int) 


r,  C  b  n  :  k  int ,  C 

V,C\-e\T,C  T<C'(p)  k  fresh 
r,  C  b  ref p  e  :  K  ref  [p) ,  Alloc(C' ,  p) 

T,C\-e:Q  ref(p),C' 

I\  C  b  !e  :  C  (p),  C 

T,C  \~  ei  :  Q  ref  {p),C  r,  C  b  e2  :  r,  C" 
r,  C  b  ei  :  =  e2  :  r,  Assign(C" ,  p  :  r) 

r  =  sp(f)  e,  s',  k  fresh 

r[is>r],fbe:r',C'  C'  <  s' 


(Ref) 


f,Gb  A L x\t.e  :  k  (s, r) 


(Assign) 


(Lam) 


r,Gb  ei  :  Q  (e, r)  — (e'.r'J.C"  T,C"  b  e2  :  t2,C" 
T2  <  t  Filter(C" ,  L)  <  e 

r,  C  b  ei  e2  :  r  ,  Mergers' ,  C1”,  L) 

r,  C  b  e  :  Q'  <r,  C" 


(App) 


r,Cb  assert(e,  Q)  :  Q  a,  C' 

f,Cb  e  :  Q'  a,C  Q'  <  Q 
F,  C  b  check(e,  Q)  ■  Q  cr,  C' 


(Assert) 

(Check) 


Figure  6:  Constraint  generation  rules 


Section  3.4.  We  use  the  function  sp{t )  to  decorate  a  standard  type  t  with  fresh  qualifier  and  store  variables: 


sp(t  ~^L  f) 


sp(a )  =  k  a 
sp(int)  =  k  int 
sp(ref(p ))  =  k  ref(p) 
k  (s,sp(t.))  — >L  ( e',sp(t ')) 


k  fresh 
k  fresh 
k  fresh 
K,s,e'  fresh 


We  briefly  discuss  the  rules  in  Figure  6 

•  (Var)  and  (Int)  are  standard.  For  (Int),  we  pick  a  fresh  qualifier  variable  k  to  annotate  n’s  type. 

•  (Ref)  adds  a  new  location  p  to  the  store  C' ,  yielding  the  store  Alloc(C' ,  p).  The  type  r  of  e  is  constrained 
to  be  compatible  with  p’s  type  in  C . 

•  (Deref)  looks  up  the  type  of  e’s  location  p  in  the  current  store  C' .  Any  qualifier  may  appear  on  e’s 
type;  qualifiers  are  checked  only  by  (Check),  see  below. 

•  (Assign)  produces  a  new  store  representing  the  assignment  of  type  r  to  location  p. 

•  (Lam)  type  checks  function  body  e  in  fresh  initial  store  e  and  with  parameter  x  bound  to  a  type  with 
fresh  qualifier  variables. 

•  (App)  constrains  To  <  r  to  ensure  that  e2’s  type  is  compatible  with  eys  argument  type.  The  constraint 
Filter(C" ,  L)  <  e  ensures  that  the  current  state  of  the  locations  that  e\  uses,  which  are  captured  by 
its  effect  set  L,  is  compatible  with  the  state  ei  expects.  The  final  store  Merge{e' ,Cn ,  L)  joins  the  store 
C"  before  the  function  call  with  the  result  store  e'  of  the  function.  Intuitively,  this  rule  gives  us  some 
low-cost  polymorphism,  in  which  functions  do  not  act  as  join  points  for  locations  they  do  not  use. 
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L={pz) 


Ko  int 

< 

S(px) 

qa  int 

< 

Allots,  px)(pV) 

qt  int 

< 

Alio c{  Alio c{e,  px),  py)(pz 

s'(py) 

< 

qc  int 

Figure  7:  Store  constraints  for  example 


•  (Assert)  adds  a  qualifier  annotation  to  the  program,  and  (Check)  checks  that  the  inferred  top-level 
qualifier  Q'  of  e  is  compatible  with  the  expected  qualifier  Q. 

Figure  7  shows  the  stores  and  store  constraints  generated  for  our  example  program.  We  have  simplified 
the  graph  for  clarity.  Here  e  is  /’ s  initial  store  and  e'  is  /’ s  final  store.  We  use  undirected  edges  for  store 
constructors  and  a  directed  edge  from  C\  to  Co  for  the  constraint  Ci  <  Co. 

We  step  through  constraint  generation.  The  store  Alloc(e,px )  models  the  allocation  of  px.  Location 
px  is  initialized  to  0,  which  is  given  the  type  kq  int  for  fresh  qualifier  variable  kq.  (Ref)  generates  the 
constraint  kq  int  <  e(px)  to  require  that  the  type  of  0  be  compatible  with  e(px).  We  model  the  allocation 
and  initialization  of  py  and  pz  similarly.  Then  we  construct  three  Assign  stores  to  represent  the  assignment 
statements.  We  give  3  and  4  the  types  Ks  int  and  k,i  int,  respectively,  where  K3  and  K4  are  fresh  qualifier 
variables. 

For  the  recursive  call  to  /,  we  construct  a  Filter  and  add  an  inclusion  constraint  on  e.  The  Merge  store 
represents  the  state  when  the  recursive  call  to  /  returns.  We  join  the  two  branches  of  the  conditional  by 
making  edges  to  e'.  Notice  the  cycle,  due  to  recursion,  in  which  state  from  e'  can  flow  to  the  Merge,  which 
in  turn  can  flow  to  p.  Finally,  the  qualifier  check  requires  that  e'(py)  has  qualifier  qc. 

3.4  Flow- Sensitive  Constraint  Resolution 

The  rules  of  Figure  6  generate  three  kinds  of  constraints:  qualifier  constraints  Q  <  Q' ,  subtyping  constraints 
t  <t',  and  store  constraints  C  <  e  (the  right-hand  side  of  a  store  constraint  is  always  a  store  variable).  A  set 
of  m  type  and  qualifier  constraints  can  be  solved  in  O(m)  time  using  well-known  techniques  [FFA99,  RM96], 
so  in  this  section  we  focus  on  computing  a  solution  S  to  a  set  of  store  constraints. 

Our  analysis  is  most  precise  if  as  few  locations  as  possible  are  non-linear.  Recall  that  linearities  nat¬ 
urally  form  a  partial  order  0  <  1  <  u.  Thus,  given  a  set  of  constructed  stores  and  store  constraints,  we 
perform  a  least  fixpoint  computation  to  determine  S{C)^n{p).  We  initially  assume  that  in  every  store, 
location  p  has  linearity  0.  Then  we  exhaustively  apply  the  rules  in  Figure  5(b)  and  the  rule  S{e)^n(p)  = 
(max,rC'|C<ff}  S(C)lm(p))  until  we  reach  a  fixpoint.  This  last  rule  is  derived  from  Figure  4. 

In  our  implementation,  we  compute  S(C)^n{p)  in  a  single  pass  over  the  store  constraints  using  Tarjan’s 
strongly-connected  components  algorithm  to  find  cycles  in  the  store  constraint  graph.  For  each  such  cycle 
containing  more  than  one  allocation  of  the  same  location  p  we  set  the  linearity  of  p  to  uj  in  all  stores  on  the 
cycle. 
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Given  this  algorithm  to  compute  S(C)^n(p),  in  principle  we  can  then  solve  the  implied  typing  constraints 
using  the  following  simple  procedure.  For  each  store  variable  e,  initialize  5(e)  to  a  map 

{p1:sp{CI{p1)), . .  ■  ,pn-sp{Ci{pn))} 

thereby  assigning  fresh  qualifiers  to  the  type  of  every  location  at  every  program  point.  Replace  uses  of  C(p) 
in  Figure  6  with  S(C)(p),  using  the  logic  in  Figure  5(a). 

Apply  the  following  two  closure  rules  until  no  more  constraints  are  generated: 

C  <  e  =+  5(G)  (p)  <  S{e){p)  for  all  p 
S(C)un(p)  =  to  =>  t  =  S(C)(p)  for  all  stores 

Assign(C,p  :  r) 

Given  a  program  of  size  n,  in  the  worst  case  this  naive  algorithm  requires  at  least  n2  space  and  time  to 
build  S(-)  and  generate  the  necessary  type  constraints.  This  cost  is  too  high  for  all  but  small  examples.  We 
reduce  this  cost  in  practice  by  taking  advantage  of  several  observations. 

Many  locations  are  flow-insensitive.  If  a  location  p  never  appears  on  the  left-hand  side  of  an  assign¬ 
ment,  then  p’s  type  cannot  change.  Thus  we  can  give  p  one  global  type  instead  of  one  type  per  program 
point.  In  imperative  languages  such  as  C,  C++,  and  Java,  function  parameters  are  a  major  source  of  flow- 
insensitive  locations.  In  these  languages,  because  parameters  are  /-values,  they  have  an  associated  memory 
location  that  is  initialized  but  then  often  never  subsequently  changed. 

Adding  extra  store  variables  trades  space  for  time.  To  compute  S(C)(p)  for  a  constructed  store 
G,  we  must  deconstruct  G  recursively  until  we  reach  a  variable  store  or  an  assignment  to  p  (see  Fig¬ 
ure  5(a)).  Because  we  represent  the  effect  constraints  compactly  (in  linear  space),  deconstructing  Filter(C,  L ) 
or  Merge{C,C'  ,L)  may  require  a  potentially  linear  time  computation  to  check  whether  p  e  L.  We  recover 
efficient  lookups  by  replacing  G  with  a  fresh  store  variable  e  and  adding  the  constraint  G  <  e.  Then  rather 
than  computing  S(C)(p )  we  compute  5(e)(p),  which  requires  only  a  map  lookup.  Of  course,  we  must  use 
space  to  store  p  in  5(e).  However,  as  shown  below,  we  often  can  avoid  this  cost  completely.  We  apply  this 
transformation  to  each  store  Merge{C,C' ,L)  constructed  during  constraint  inference. 

Not  every  store  needs  every  location.  Rather  than  assuming  5(e)  contains  all  locations,  we  add  needed 
locations  lazily.  We  add  a  location  p  to  5(e)  the  first  time  the  analysis  requests  e(p)  and  whenever  there  is 
a  constraint  C  <  e  or  e  <  G  such  that  p  €  5(G).  Stores  constructed  with  Filter  and  Merge  will  tend  to 
stop  propagation  of  location,  saving  space  (e.g.,  if  Filter(C,L)  <  e,  p  G  5(e),  but  p  $  L,  then  we  do  not 
propagate  p  to  G). 

We  can  extend  this  idea  further.  For  each  qualifier  variable  k,  inference  maintains  a  set  of  possible 
qualifier  constants  that  are  valid  solutions  for  k.  If  that  set  contains  every  constant  qualifier,  then  k  is 
uninteresting  (i.e.,  n  is  constrained  only  by  other  qualifier  variables),  otherwise  n  is  interesting.  A  type  r  is 
interesting  if  any  qualifier  in  r  is  interesting,  otherwise  r  is  uninteresting.  We  then  modify  the  closure  rules 
as  follows: 

G  <  £  =»  S(C)(p)  <  S(e)(p) 

for  all  p  G  5(G)  or  5(e)  s.t. 

5(C)(p)  or  S(e)(p)  interesting 

5(G)K„(p)=w  =>  r  =  S(C)(p ) 

for  all  Assign(C,  p  :  r)  s.t.  r  or  S(C)(p)  interesting 

In  this  way,  if  a  location  p  is  bound  to  an  uninteresting  type,  then  we  need  not  propagate  p  through  the 
constraint  graph. 

Figure  8  gives  an  algorithm  for  lazy  location  propagation.  We  associate  a  mark  with  each  p  in  each 
5(e)  and  with  p  in  Assign(C,  p  :  r).  Initially  this  mark  is  not  set,  indicating  that  location  p  is  bound  to  an 
uninteresting  type. 
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If  a  qualifier  variable  k  appears  in  S(e)(p),  we  associate  the  pair  ( p,C )  with  k,  and  similarly  for  Assign 
stores.  If  during  constraint  resolution  the  set  of  possible  solutions  k  changes,  we  call  Propacate(p,  C )  to 
propagate  p,  and  in  turn  n,  through  the  store  constraint  graph. 

If  PROPAGATE(p,  C)  is  called  and  p  is  already  marked  in  C,  we  do  nothing.  Otherwise,  Back-propQ  and 
F O RWA rd-prop()  make  appropriate  constraints  between  S(C)(p)  and  S(C')(p)  for  every  store  C  reachable 
from  C.  This  step  may  add  p  to  C1  if  C'  is  a  store  variable,  and  the  type  constraints  Back-propQ  and 
F O RWA RD-PROP0  generate  may  trigger  subsequent  calls  to  PropagateQ. 

Consider  again  our  running  example.  Figure  9  shows  how  locations  and  qualifiers  propagate  through 
the  store  constraint  graph.  Dotted  edges  in  this  graph  indicate  inferred  constraints  (discussed  below).  For 
clarity  we  have  omitted  the  Alloc  edges  and  the  base  types. 

The  four  type  constraints  in  Figure  7  are  shown  as  directed  edges  in  Figure  9.  For  example,  the  constraint 
kq  int  <  e(px)  reduces  to  the  constraint  kq  <  nx,  which  is  a  directed  edge  Ko  — >  kx.  Adding  this  constraint 
does  not  cause  any  propagation;  this  constraint  is  among  variables.  Notice  that  the  assignment  of  type 
Ks  int  to  px  also  does  not  cause  any  propagation. 

The  constraint  qa  int  <  Alloc(e,  px)(py)  reduces  to  qa  int  <  e(py),  which  reduces  to  qa  <  ny.  This 
constraint  does  trigger  propagation.  Propagate^,  e)  first  pushes  py  backward  to  the  Filter  store.  But 
since  py  ^  L,  propagation  stops.  Next  we  push  py  forward  through  the  graph  and  stop  when  we  reach  the 
store  Assign)-,  p.y  :  qc  int)]  forward  propagation  assumes  that  this  is  a  strong  update. 

Since  Assign)- ,  py  :  qc  int )  contains  an  interesting  type,  py  is  propagated  from  this  store  forward  through 
the  graph.  On  one  path,  propagation  stops  at  the  Filter.  The  other  path  yields  a  constraint  qc  <  ny.  Notice 
that  the  constraint  n'y  <  qc  remains  satisfiable. 

The  constraint  qt,  <  kz  triggers  a  propagation  step  as  before.  However,  this  time  kz  G  L,  and  during 
backward  propagation  when  we  reach  Filter  we  must  continue.  Eventually  we  reach  Assign)-,  p~  :  K4  int )  and 
add  the  constraint  K4  <  kz.  This  in  turn  triggers  propagation  from  Assign)-,  pz  :  K4  int).  This  propagation 
step  reaches  e'  and  adds  pz  to  S(e')  and  generates  the  constraint  K4  <  n'z. 

Finally,  we  determine  that  in  the  Assign  stores  px  and  py  are  linear  and  p~  is  non-linear.  Thus  the  update 
to  pz  is  a  weak  update,  which  yields  an  equality  constraint  kz  =  K4,  indicated  with  a  double-dotted  line. 

This  example  illustrates  three  kinds  of  propagation.  The  location  px  is  never  interesting,  so  it  is  not 
propagated  through  the  graph.  The  location  py  is  propagated,  but  propagation  stops  at  the  strong  update 
to  py  and  also  at  the  Filter ,  because  the  (Down)  rule  in  Figure  2  was  able  to  prove  that  py  is  purely  local 
to  /.  The  location  pz,  on  the  other  hand,  is  not  purely  local  to  /,  and  thus  all  instances  of  pz  are  conflated, 
and  pz  admits  only  weak  updates. 


4  Restrict 


As  mentioned  in  the  introduction,  type  inference  may  fail  because  a  location  on  which  a  strong  update 
is  needed  may  be  non-linear.  In  practice  a  major  source  of  non-linear  locations  is  data  structures.  For 
example,  given  a  linked  list  1,  our  alias  analysis  cannot  distinguish  l->lock  from  l->next->lock,  hence 
both  are  non-linear. 

Our  solution  to  this  problem  is  to  add  a  new  form  restrict  a? ~e\  ine2  to  the  language.  Intuitively,  this 
declares  that  of  all  aliases  of  e\,  only  the  particular  value  bound  to  x  will  be  used  within  eo.  For  example: 


restrict  x  =  y  in 

x  : =  . . . ;  /*  valid  */ 
y  :=  /*  invalid  */ 


The  first  assignment  through  x  is  valid,  but  the  assignment  through  y  is  forbidden  by  restrict. 

We  check  restrict  using  the  following  type  rule,  which  is  integrated  into  the  first  inference  pass  of 
Figure  2: 


T  b  ei  =>  e)  :  ti]  L 1  1. 1  =  ref(p)  p,  p  fresh  Ci(p')  =  Ci(p ) 

r[a;  1 — y  ref(p')]  b  e 2  e'2  :  i2;  T2 

p  L2  p  Cf  /oo(  I'.  0.  t.->) 

r  b  restrict  x  =ei  in e2  restrict*3  x  =e[  in e2  :  f2;  L\  U  L2  U  {p} 


(Restrict) 
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Propagate  (p,  e)  = 
case  C  of 

s: 

add  p  :  sp(Ci(p))  to  5(e)  if  not  already  in  S(s) 
if  p  is  not  marked  in  e 
mark  p  in  5(e) 

Forward-prop(C,  p,  5(e)(p)) 
for  each  C'  such  that  C  <  e 
Back-prop(C',  p,  5(e)(p)) 

Assign{C' ,  p  :  r): 

if  p  is  not  marked  in  Assign(C' ,  p  :  r) 
mark  p  in  Assign{C' ,  p  :  r) 
Forward-prop(C,  p,  t) 

Back-prop(C,  p,  t)  = 
case  C  of 

s: 

add  p  :  sp(Ci{p))  to  S(s)  if  not  already  in  S(s) 

S(s)(p)  <  t 

Alloc{C',p '): 

Back-prop(C",  p,  t) 

Merge(C',C",L): 
if  p  G  L 

then  Back-PROP(C",  p,  t) 
else  Back-PROP(C"',  p,  t) 

FilteriC ,  L): 
if  p  &  L 

then  Back-PROP(C',  p,  t) 

Assign(C' ,  p  :  t')\ 
if  P  =  P 

then  t'  <  T 

else  Back-PROP(C",  p,  t) 


Forward- prop  (Cl,  p,  t)  = 
for  each  £  such  that  C  <  e 

add  p  :  sp{Ci(p))  to  S(s)  if  not  already  in  5(e) 
t  <  5(e)(p) 

for  each  C'  such  that  C'  is  constructed  from  C 
case  C  of 
Alloc{C,  p'): 

Forward-prop(C7',  p,  t) 

Merge(Ci,  G%,  L)-. 

if  p  €  L  and  C  =  Ci 

then  Forward-PROP(C',  p,  r) 
if  p  $  L  and  C  =  Ci 

then  Forward-PROP(C",  p,  r) 

Filter(C,  L): 
if  p  €  L 

then  Forward-prop(C",  p,  t) 

Assign{C,  p  :  t1): 

:f  P  /  l> 

then  Forward-PROP(C',  p,  r) 


Figure  8:  Lazy  location  constraint  propagation 
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Figure  9:  Constraint  propagation 

Here  we  bind  x  to  a  type  with  a  fresh  abstract  location  p'  to  distinguish  dereferences  of  x  from  dereferences  of 
other  aliases  of  e\.  The  constraint  p  $  L2  forbids  location  p  from  being  dereferenced  in  e2;  notice  dereferences 
of  p'  within  e2  are  allowed.  We  require  that  p'  not  escape  the  scope  of  e2  with  p'  $  locs(Y.  r.  r2).  and  we  also 
add  p  to  the  effect  set.  We  translate  restrict  into  the  target  language  by  annotating  it  with  the  location  p' 
that  x  is  bound  to.  A  full  discussion  of  restrict,  including  a  soundness  proof,  can  be  found  in  a  technical 
report  [FA01]. 

We  use  restrict  to  locally  recover  strong  updates.  The  key  observation  is  that  the  location  p  of  e\  and 
the  location  p'  of  x  can  be  different.  Thus  even  if  the  linearity  of  p  is  uj,  the  linearity  of  p'  can  be  1.  Therefore 
within  the  body  of  e2  we  may  be  able  to  perform  strong  updates  of  p' .  When  the  scope  of  restrict  ends, 
we  may  need  to  do  a  weak  update  from  p'  to  p. 

For  example,  suppose  that  we  wish  to  type  check  a  state  change  of  some  lock  deep  within  a  data  structure, 
and  the  location  of  the  lock  is  non-linear.  The  following  is  not  atypical  of  Linux  kernel  code: 

spin_lock(&a->b [c] .d->lock) ;  /*  invalid;  */ 

...  /*  non-linear  loc  */ 

spin_unlock(&a->b [c] .d->lock) ; 

Assuming  the  .  .  .  above  contains  no  accesses  to  aliases  of  the  lock  and  does  not  alias  the  lock  to  a  non-linear 
location,  we  can  modify  the  code  to  type  check  as  follows: 

restrict  lock  =  &a->b [c] . d->lock  in 

spin_lock(lock) ;  /*  valid  */ 

spin_unlock(lock) ; 

In  our  flow-sensitive  step,  we  use  the  following  inference  rule  for  restrict: 

r,r  •  -  ,  :  Q  ref  (p),  C' 

C"  =  Alloc(C' ,  p)  C'{p)  <  C"{p') 

_ in^ref(p')],C"Ye2:r2,C"' _  (Reatrict) 

r,Ch  restrict'’  x  =ei  in  e2  :  r2,  Assign(C'" ,  p  :  C'"  (p)) 

In  this  rule,  we  infer  a  type  for  e\,  which  is  a  pointer  to  some  location  p.  Then  we  create  a  new  store 
C"  in  which  the  location  p'  of  x  is  both  allocated  and  initialized  C'(p).  In  C" ,  and  with  x  added  to  the 
type  environment,  we  evaluate  e2.  Finally,  the  result  store  is  the  store  C'"  with  a  potentially  weak  update 
assigning  the  contents  of  p'  to  p. 
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S(Merge(C,C',L))(p) 
S(Filter(C,  L))(p) 


S(Merge(C ,  C',L))Un{p) 


S(Filter(C,L))lin(p) 


I  S(C)(p) 

\  S(C')(p) 

S(C)(P) 

I  S(C)lin(p) 
1  S(C)lm(p) 

/  S(C)lm{p) 

1  0 


al{p)  £  IV  rw(p)  G  L 
otherwise 

l(p)  £  IV  rw{p)  G  L 

al(p )  G  L 
otherwise 

al(p )  G  IV  rw{p)  G  L 
otherwise 


Figure  10:  New  definition  of  S  with  allocation  and  read-write  effects 


5  Experiments 

We  have  used  a  prototype  implementation  of  our  analysis  to  check  two  program  properties:  locking  in  the 
2.4.9  Linux  kernel  device  drivers  and  uses  of  the  C  Stream  Library.  Our  implementation  is  sound  up  to  the 
unsafe  features  of  C:  type  casts,  variable-argument  functions,  ill-defined  pointer  arithmetic,  and  conversions 
from  arbitrary  integers  to  pointers.  We  currently  make  no  attempt  to  track  the  effect  of  any  of  these  features 
on  aliasing,  except  for  the  special  case  of  type  casting  of  the  result  of  malloc-like  functions.  In  combination 
with  a  system  for  enforcing  memory  safety,  such  as  CCured  [NMW02],  our  implementation  would  be  sound. 

In  our  implementation,  we  do  not  allow'  strong  updates  on  locations  containing  functions.  This  improves 
efficiency  because  we  never  need  to  recompute  S{C)^n{p) — weak  updates  w'ill  not  add  constraints  between 
stores. 

Additionally,  observe  that  allocations  affect  linearities  but  not  types,  and  reads  and  writes  affect  types  but 
not  linearities.  Thus  in  our  implementation  wTe  also  improve  the  precision  of  the  analysis  by  distinguishing 
read-write  and  allocation  effects.  Formally,  instead  of  effects  of  the  form  p,  we  introduce  effects  rw(p)  for  a 
read  or  write  of  location  p,  and  al(p )  for  an  allocation  of  location  p.  We  modify  Figure  2  so  that  (Ref)  yields 
effect  al(p)  and  (Deref)  and  (Assign)  yield  effect  rw(p). 

Then  we  modify  the  definition  of  S  for  Merge  and  Filter  as  shown  in  Figure  10.  The  first,  second,  and 
last  case  are  as  before.  In  the  third  case,  we  use  only  the  allocation  effects  of  L  when  computing  the  linearity 
of  a  location  in  a  Merge  store.  Intuitively  this  means  that  functions  that  do  not  allocate  a  location  p  do 
not  act  as  join  points  for  location  p  with  respect  to  linearities.  We  could  also  improve  the  precision  of  the 
analysis  further  by  distinguish  read  and  write  effects  from  each  other. 

5.1  Linux  Kernel  Locking 

The  Linux  kernel  includes  two  primitive  locking  functions,  which  are  used  extensively  by  device  drivers: 

void  spin_lock(spinlock_t  *lock) ; 
void  spin_unlock(spinlock_t  *lock) ; 

We  use  three  qualifiers  locked,  unlocked,  and  T  (unknown)  to  check  locking  behavior.  The  subtyping 
relation  is  locked  <  T  and  unlocked  <  T.  We  assign  spin_lock  the  type 

( C,ref(p ))  — ( Assign(C,p  :  locked  spinlock_t),  void) 

where 

C(p)  <  unlocked  spinlock_t 

We  omit  the  function  qualifier  since  it  is  irrelevant.  The  type  of  spin_lock  requires  that  the  lock  passed  as 
the  argument  be  unlocked  (see  the  where  clause)  and  changes  it  to  locked  upon  returning.  The  signature  for 
spin_unlock  is  the  same  with  locked  and  unlocked  exchanged.  Since  our  implementation  currently  lacks 
parametric  polymorphism,  we  inline  calls  to  spin_lock  and  spin_unlock. 
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Using  these  type  signatures  we  can  check  for  two  kinds  of  errors:  deadlocks  from  acquiring  a  lock  already 
held  by  the  same  thread,  and  attempting  to  acquire  or  release  a  lock  in  an  unknown  (T)  state. 

We  analyzed  513  whole  device  driver  modules  (a  whole  module  includes  all  the  files  that  make  up  a  single 
driver).  A  module  must  meet  a  well-specified  kernel  interface,  which  we  model  with  a  main  function  that 
non-deterministically  calls  all  possible  driver  functions  registered  with  the  kernel. 

We  have  not  yet  finished  reviewing  the  analysis  results  for  all  modules.  So  far  we  have  found  14  apparently 
new  locking  bugs,  including  one  which  spanned  multiple  files.  Five  of  the  apparent  bugs  involve  deadlocks, 
in  which  a  function  tries  to  acquire  a  lock  already  held  by  a  function  above  it  in  the  call  chain.  For  example, 
the  emulOkl  module  contains  a  deadlock:  void): 

void  emulOkl_mute_irqhandler (struct  emulOkl_card  *card)  { 
struct  patch_manager  *mgr  =  &card->mgr; 

...  spin_lock_irqsave(&mgr->lock,  flags); 
emulOkl_set_oss_vol(card,  ...);  ... 

} 

void  emulOkl_set_oss_vol (struct  emulOkl_card  *card,  ...)  { 

...  emulOkl_set_volume_gpr (card,  ...);  ... 

} 

void  emulOkl_set_volume_gpr (struct  emulOkl_card  *card,  ...)  { 
struct  patch_manager  *mgr  =  &card->mgr; 

...  spin_lock_irqsave(&mgr->lock,  flags);  ... 

} 

Note  detecting  this  error  requires  interprocedural  analysis. 

One  of  our  goals  is  to  understand  how  often,  and  why,  our  system  fails  to  type  check  real  programs.  We 
have  categorized  every  type  error  in  an  earlier  experiment  where  we  separately  analyze  each  of  910  driver 
files  and  remove  the  T  qualifier  so  that  locked  and  unlocked  are  incomparable.  In  this  experiment,  of  the 
52  files  that  fail  to  type  check,  11  files  have  locking  bugs  and  the  remaining  41  files  have  type  errors.  Half  of 
these  type  errors  are  due  to  incorrect  assumptions  eliminated  by  moving  to  whole  module  analysis,  and  the 
remaining  type  errors  fall  into  two  main  categories. 

In  most  cases  the  problem  is  that  our  alias  analysis  is  not  strong  enough  to  type  check  the  program,  often 
because  our  current  implementation  does  not  have  parametric  polymorphism  for  store  locations.  We  plan 
to  add  this  feature  using  the  techniques  of  [FRD00,  RF01].  In  another  common  situation  there  are  multiple 
aliases  of  a  location,  but  only  one  alias  is  actually  used  in  the  code  of  interest;  we  can  type  check  this  pattern 
using  restrict.  Not  surprisingly,  larger  programs  have  more  problems  with  spurious  aliasing,  so  we  believe 
both  polymorphism  and  restrict  are  most  important  for  large  programs. 

A  less  common  class  of  type  errors  arises  when  locks  are  conditionally  acquired  and  released.  In  this  case, 
a  lock  is  acquired  if  a  predicate  P  is  true.  Before  the  lock  is  released,  P  is  tested  again  to  check  whether 
the  lock  is  held.  Our  system  is  not  path  sensitive,  and  our  tool  signals  a  type  error  at  the  point  where  the 
path  on  which  the  lock  is  acquired  joins  with  the  path  on  which  the  lock  is  not  acquired  (since  we  did  not 
use  T  in  these  single  file  experiments).  Most  of  these  examples  could  be  rewritten  with  little  effort  to  pass 
our  type  system.  In  our  opinion,  this  would  usually  make  the  code  clearer  and  safer — the  duplication  of  the 
test  on  P  invites  new  bugs  when  the  program  is  modified. 

Even  after  further  improvements,  we  expect  some  dynamically  correct  programs  will  not  type  check.  As 
future  work,  we  propose  the  following  solution.  The  qualifier  T  represents  an  unknown  state.  We  can  use 
the  information  in  the  constraints  to  automatically  insert  coercions  to  and  from  T  where  needed.  During 
execution  these  coercions  perform  runtime  tests  to  verify  locks  are  in  the  correct  state.  Thus,  our  approach 
can  introduce  dynamic  type  checking  in  situations  where  we  cannot  prove  safety  statically. 

We  added  restrict  annotations  to  the  emulOkl  module,  which  is  the  Linux  kernel  module  that  yielded 
the  largest  number  of  false  positives  because  non-linear  locations  could  not  be  strongly  updated.  Using 
restrict,  we  eliminated  all  of  these  false  positives.  This  supports  our  belief  that  restrict  is  the  right 
tool  for  dealing  with  (necessarily)  conservative  alias  analysis.  Many  of  these  restrict  annotations  were 
needed  because  of  the  current  lack  of  location  polymorphism;  we  must  leave  an  accurate  assessment  of  how 
burdensome  restrict  is  to  future  work. 
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$open_u 


Figure  11:  Sub  typing  relation  among  C  stream  library  qualifiers 

5.2  C  Stream  Library 

As  mentioned  in  the  introduction,  the  C  stream  library  interface  contains  certain  sequencing  constraints. 
For  example,  a  file  must  be  opened  for  reading  before  being  read.  A  special  property  of  the  C  stream  library 
is  that  the  result  of  fopen  must  be  tested  against  NULL  before  being  used,  because  fopen  may  or  may  not 
succeed. 

We  model  C  stream  library  file  states  using  the  qualifier  partial  order  given  in  Figure  11.  This  partial 
order  extends  the  partial  order  in  Figure  1  with  four  additional  qualifiers  $open_u,  $read_u,  $write_u,  and 
$readwrite_u.  The  qualifier  $X_u  stands  for  a  file  opened  in  state  X  that  has  not  yet  been  checked  against 
NULL. 

The  type  signature  for  f  close  is 

( C,ref(p ))  — (Assign(C,  p  :  $closed  FILE),  int) 
where 

C(p )  <  $open  FILE 


and  the  type  signature  for  fopen  is 

( C,mocle )  — {Assign(Alloc(C, p), p  ■  mode  FILE),  ref(p )) 

where 

C(p)  <  $closed  FILE 

The  mode  is  passed  as  a  parameter  to  the  fopen  function.  In  practice  the  mode  is  usually  a  constant  string, 
and  therefore  we  can  determine  the  correct  mode  qualifier,  $read_u,  $write_u,  or  $readwrite_u,  by  a  simple 
syntactic  comparison  against  possible  mode  strings.  If  we  cannot  determine  the  mode  qualifier  syntactically, 
we  issue  a  warning  and  mark  the  file  as  $open_u. 

Finally,  functions  that  read  and  write  files  require  appropriate  qualifiers  for  their  file  arguments.  For 
example,  the  fgetc  function,  which  reads  a  character  from  a  stream,  has  the  signature 

(C,  ref  {p))  — (i C,int ) 

where 

C(p)  <  $read  FILE 

Using  these  qualifiers  we  can  type  check  the  following  C  code  fragment: 

if  ((file  =  fopen (filename ,  "r"))  !=  NULL)  { 

. . .  fgetc(f ile) ;  ... 
f close(f ile) ; 

}  else  { 

printf  ("Failed  to  open  7,s",  filename); 

} 

At  the  call  to  fopen,  we  syntactically  recognize  the  string  "r"  and  determine  that  the  file  is  being  opened 
for  read.  Thus  the  location  p  corresponding  to  the  opened  file  is  given  the  type  $read_u  FILE.  We  treat 
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Figure  12:  Resource  usage  for  whole  module  analysis 


the  comparison  between  the  pointer  to  location  p  and  NULL  as  a  kind  of  type  case.  We  analyze  the  true 
branch  starting  in  the  store  Assign(C,  p  :  $read  FILE),  and  we  analyze  the  false  branch  starting  in  the  store 
Assign(C,  p  :  $closed  FILE).  We  use  conditional  constraints  to  relate  the  $read_u  qualifier  in  C  to  $read 
at  the  true  branch. 

The  class  of  C  stream  library  usage  errors  our  tool  can  detect  includes  files  used  without  having  been 
opened  and  checked  against  NULL,  files  opened  in  an  incompatible  mode,  and  files  accessed  after  being  closed. 

We  tried  our  tool  on  two  application  programs,  man-1.5hl  and  sendmail-8 . 11 . 6.  We  were  primarily 
interested  in  the  performance  of  our  tool  on  a  more  complex  application  (see  below),  as  we  did  not  expect 
to  find  any  latent  stream  library  usage  bugs  in  such  mature  programs.  However,  we  did  find  one  minor  bug 
in  sendmail,  in  which  an  opened  log  file  is  never  closed  in  some  circumstances. 

5.3  Precision  and  Efficiency 

The  algorithm  described  in  Section  3.4  is  carefully  designed  to  limit  resource  usage.  Figure  12  shows  time 
and  space  usage  of  whole  module  analysis  versus  preprocessed  lines  of  code  for  513  Linux  kernel  modules. 
All  experiments  were  done  on  a  dual  processor  550  MHz  Pentium  III  with  2GB  of  memory  running  RedHat 
6.2. 
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We  divide  the  resource  usage  into  C  parsing  and  type  checking,  flow-insensitive  analysis,  and  flow- 
sensitive  analysis.  Flow-insensitive  analysis  consists  of  the  alias  and  effect  inference  of  Figure  2  together 
with  flow-insensitive  qualifier  inference  [FFA99] .  Flow-sensitive  analysis  consists  of  the  constraint  generation 
and  resolution  described  in  Sections  3. 3-3. 4,  including  the  linearity  computation. 

The  graphs  show  the  space  overhead  of  flow-sensitive  analysis  is  relatively  small  and  appears  to  scale  well 
to  large  modules.  For  all  modules  the  space  usage  for  the  flow-sensitive  analysis  is  within  30%  of  the  space 
usage  for  the  flow-insensitive  analysis.  The  running  time  of  the  analysis  is  more  variable,  but  the  absolute 
running  times  are  within  a  factor  of  2.3  of  the  flow-insensitive  running  times. 

The  analysis  of  sendmail-8. 11.6,  with  175,493  preprocessed  source  lines,  took  168  seconds  and  266MB; 
man-1. 5hl,  with  16,411  preprocessed  source  lines,  took  1.99  seconds  and  32MB.  The  time  usage  for  sendmail 
suggests  that  C  stream  library  analysis  is  more  expensive  than  Linux  kernel  locking  analysis.  The  higher 
running  time  is  most  likely  because  sendmail  uses  stream  operations  more  often  and  more  freely  than  a 
typical  Linux  kernel  module  uses  spin  locks.  Because  our  algorithm  is  demand  driven,  more  demand  means 
more  computation. 


6  Conclusion 

We  have  presented  a  system  for  extending  standard  type  systems  with  flow-sensitive  type  qualifiers.  We 
have  given  a  lazy  constraint  resolution  algorithm  to  infer  type  qualifier  annotations  and  have  shown  that  our 
analysis  is  effective  in  practice  by  finding  a  number  of  new  locking  bugs  in  the  Linux  kernel. 
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